Types for XIO Clocks 



Francisco Martins 

LaSIGE & University of Lisbon 
Portugal 

fmartinsOdi .fc.ul.pt 



Vasco T. Vasconcelos 

LaSIGE & University of Lisbon 
Portugal 

vvOdi .fc.ul.pt 



Tiago Cogumbreiro 

LaSIGE & University of Lisbon 
Portugal 

cogumbreiroOdi .fc.ul.pt 



XIO is a modern language built from the ground up to handle future parallel systems, from multicore 
machines to cluster configurations. We take a closer look at a pair of synchronisation mechanisms: 
finish and clocks. The former waits for the termination of parallel computations, the latter allow 
multiple concurrent activities to wait for each other at certain points in time. In order to better 
understand these concepts we study a type system for a stripped down version of XIO. The main 
result assures that well typed programs do not run into the errors identified in the XIO language 
reference, namely the ClockUseException. The study will open, we hope, doors to a more flexible 
utilisation of clocks in the XIO language. 



1 Introduction 



New high-level concurrency primitives are needed more than ever, now that multicore machines lay on 
our desks and laps. One such primitive is clocks, a generalisation of barriers introduced in the XIO 
programming language [2]. Barriers are a collective synchronisation mechanism common in Single Pro- 
gram Multiple Data (SPMD) programs ||3l[I21. Distinct from synchronisation mechanisms like locks 
and monitors that let the programmer think about the access to a resource, barriers allow reasoning about 
process workflow. Clocks are a sophisticated form of barriers that feature dynamic sets of participants 
for more dynamic programming paradigms, and a two-phase synchronisation (or fuzzy barrier) for im- 
proved processor utilisation 0. The construct is integrated in the XIO language with a promise that it 
cannot introduce deadlocks. Another primitive, finish, causes an activity to block (i.e., to suspend its ex- 
ecution) until all its sub-activities have completed. Dynamic, unbounded spawning of activities and the 
finish construct enable fork/join paiallelism. The fifth version of language Cilk introduced a specialised 
"work-stealing" scheduler algorithm that takes advantage of the fork/join model to yield highly efficient 
language [4] . This style of parallel programming and its run-time system (the work-steahng scheduler) 
were then incorporated in mainstream languages, e.g., the fork/join framework proposed for Java 7 IH. 

Even though the XIO language specification [8] provides a clear, plain English, description of the 
intended semantics (and properties) of the language, and a formalisation of the semantics |9] allows to 
prove a deadlock freedom theorem, we decided to investigate a simpler setting in which similar results 
could be obtained. The aim is not only to obtain a progress property for typable programs based on a 
simple type system, but also to hopefully provide for clock-safe extensions of the XIO language itself. 

Towards this end, we have stripped XIO from most of its features, ending up with a simple con- 
current language equipped with finish and the full functionality of XIO clocks, which we call "XIO 
restricted to clocks," XIO Idocks for short. For this language we have devised a simple operational se- 
mantics with thread (or activity as called in XIO) local and global views of (heap allocated) clocks. We 
have also crafted a simple type system, based on singleton types, drawing expertise from previous work 
on low-level programming languages |[T3l . Typable programs are exempt from clock related errors; we 
conjecture that typable programs enjoy a form of progress property. 
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Saraswat and Jagadeesan study the XIO programming model, by presenting a formal model of the 
language that includes clocks, async/finish, conditional atomic blocks, and a hierarchic shared mem- 
ory [9]. The authors formalise the semantics of the language with a small-step operational semantics, de- 
fine a bisimulation, and establish that XIO programs without conditional atomic blocks do not deadlock. 
Lee and Palsberg present a core model for XIO, an imperative language augmented with async/finish 
and atomic blocks suited for inter-procedural analysis through type inference [7 |. The authors present an 
operational semantics based on [9J and a type system that identifies may-happen-parallelism, further ex- 
plored in m. Java features, since version 5, cyclic barriers, j ava . util . concurrent . CyclicBarrier. 
Unlike XIO clocks these barriers have a fixed set of participants, defined at initialisation time. 

This paper constitutes an archival version (post-proceedings) of a workshop paper produced in late 
2009. Three of the language extensions proposed at that time have been incorporated in the XIO language 
definition [8], further discussed in Section|4] They are: 

• Aliasing, introduced in version 2.01, January 2010. Prior versions imposed a restriction on how 
clock values could be aliased, "The initializer for a local variable declaration of type Clock must 
be a new clock expression. Thus XIO does not permit aliasing of clocks" (page 123, version 2.00). 

• Clocks can be transmitted to a spawned activity if they are created in the scope of the enclosing 
finish, introduced in version 2.05, July 2010. Before we could read, "While executing S [the body 
of a finish], an activity must not spawn any clocked asyncs'Q (page 141, version 2.04). Shirako 
et al. included this extension even prior to our work lITOl . 

• Resume state inheritance, introduced in version 2.05, July 2010. Resumed clocks can be transmit- 
ted to forked activities. Prior to version 2.05 we could read, "It is a static error if any activity has a 
potentially live execution path from a resume statement on a clock c to a async spawn statement 
(which registers the new activity on c) unless the path goes through a next statement" (page 153, 
version 2.04). 

In summary, the contributions of this work are: 

• a simple operational semantics for activities, finish, and clocks that allows to better understand 
these constructs, 

• a type systems allowing to prove safety and progress properties (alternative to the constraint-based 
system 191), and 

• the promise of a more flexible utilization of the clock constructs. 

The rest of this paper presents the syntax in Section [2] the (operational) semantics and the notion of 
run-time errors in Section |3] the type system and some examples in Section |4j and the main result in 
Section [5] We conclude, in Section [6} discussing an alternative model for the semantics and pointing 
directions for future work. 

2 Syntax 

Object-oriented and type-safe, XIO provides for support for concurrency, parallelism, and distribution. 
Of particular interest to us is the finish synchronisation mechanism that waits for the termination of 
parallel computations and the clock primitive that allows forcing multiple concurrent activities to wait 
for each other at certain points in time. 



In XIO a clocked async corresponds to an activity registered with at least one clock upon creation. 
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async v e 
makeClock 
drop V 
finish e 
next 

resume v 
let ;c = e in e 



Expressions 
value 

fork activity 
new clock 
deregister from v 
wait to terminate 
advance phase 
ready to advance on v 
local declaration 



V ::= Values 
X variable 
I unit 



Figure 1: Top-level syntax of XIO |ciocks 



The top-level, or programmer's, language we address, XIO Idocks (XIO restricted to clocks and fin- 
ish), is a subset of the XIO language, generated by the grammar in Figure [TJ and relies on a base set 
of variables ranged over by x. An XIO Idocks program is an expression e that can operate on activities, 
clocks, or unit () values. To construct programs we compose expressions through the standard let con- 
struct let X = ^1 in e2, which binds variable x to the result of expression e in the scope of expression e'. 

Below we present an example program with the purpose of illustrating the syntax and informally 
presenting the semantics of the language. The example is composed of three activities an outermost 
activity ai, defined from line 2 to line 16, an inner activity aa, spawned at line 4, and another inner 
activity ai,, spawned at line 5 and lasting until line 11. Along the example we make use of the derived 
expression ei;e2 that abbreviates let x = in where x not free in e2- 



// activity a\ 1 

finish 2 

let X = makeClock in ( 3 

finish async e^ ; // activity a2 4 

async x { // activity aj, 5 

e\ ; 6 

resume x; 7 

e2\ 8 

next; 9 

ey, 10 

dropx); 11 

e^; 12 

resume x; 13 

next; 14 

es; 15 

drop x) 16 



Activities can be registered with zero or more clocks and may share clocks with other activities. A 
clock can thus count with zero or more different registered activities, which are also called participants. 
When an activity a is registered with clock x, we say that x is a clock held by a. Activities may only 
register themselves with clocks via two different means: when they explicitly create a clock (line 3, 
makeClock, creates a clock and registers activity a\ with the clock), and when they inherit clocks from 
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its parent activity in a spawning operation (line 5 spawns activity and registers it with the clock asso- 
ciated with variable x). Expression drop deregisters an activity from a clock (line 11, drop x deregisters 
activity from clock x, whereas line 16 deregisters activity a\ from x). Activities are disallowed to 
manipulate clocks they are not registered with. 

In XIO |ciocks» an activity synchronises via two different methods: by waiting for every activity 
spawned by expression e to terminate (line 4 only terminates when activity a2 and all its sub-activities 
terminate), and by waiting for its held clocks to advance a phase (activity a^ waits at line 9, whereas 
activity ai waits at line 14). XIO distinguishes between local and global termination of an expression. 
Local termination of an expression corresponds to concluding its evaluation (reducing to a value v). An 
expression terminates globally when it terminates locally and each activity spawned by the expression 
has also terminated globally. Expression finish e converts the global termination of expression e into 
a local termination (line 2 waits for the expression in lines 3-16 to terminate, meaning that it waits as 
well for the termination of activities a2 and aj, ; line 4 waits for activity a2 (the result of the evaluation 
of async eo ) to terminate before launching the sub-activity aj, in line 5). The second method to syn- 
chronise activities is using clocks. Groups of activities, defined by the participants of a clock, evaluate 
concurrently until they reach the end of a phase. When every participant of the group reaches the end 
of the phase, then all move to the next phase, while still executing concurrently. Phases are delimited 
by expression next; activities evaluate this expression to mark the end of a phase (activities ai and a^ 
synchronise at lines 9 and 14). 

An activity can inform all other participants of a clock x that it has completed its phase by using an 
expression of the form resume x, thus making clocks act as fuzzy barriers IS (Une 7). Expression resume 
can be viewed as an optimisation to diminish contention upon advancing a phase: it allows activities 
blocked on next to cease waiting for such activities (which can become at most one phase behind the 
clock's phase). In the example, expression ej might execute at the same time as expression ^5, since 
activity a^ may trigger (at line 5) activity ai to advance clock x (blocked at line 11), thus evaluating 
expressions ^2 and e^ in parallel. If we omit expression resume x from this example, then expressions e2 
and ^5 cannot evaluate in parallel. 

Clocks can be implemented via a (sophisticated) ?i-ary synchronisation mechanism that includes a 
natural number representing its global phase, initially set to zero. Advancing a clock's phase amounts to 
incrementing its global phase when every registered activity has quiesced; an activity is quiescent on a 
clock X after performing a resume x. An activity resumes all its held clocks together by evaluating next 
and suspends itself until these clocks become ready to advance to the next phase. 

3 Operational Semantics 

This section describes the operation semantics of our language, a possible execution of the example 
described in Section[2) and the notion of run-time errors. 

Operational Semantics Figure |2] depicts the run-time syntax of our language. The run-time system 
relies on one additional set, clock names (or heap addresses, since clocks are the only data structures 
we allocate in the heap), ranged over by c. A state 5 of an XIO Idocks computation comprises a shared 
heap H and a set of named activities A that run concurrently. Activity names, /, are taken from the set of 
variables introduced in Section [2] The heap stores clock values h, triples comprising a natural number p 
representing its global phase, a set R with the registered activities, and another set Q with the quiesced 
activities. These sets keep track of the activities that synchronise in the clock (R) and the activities that are 
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S ::= H,A States 

H ::= {ci: h\, . . . ,Cn' h„} Heaps 

A ::= {/i : ai,...,/„: a„} Sets of named activities 

h ::= {p,R,Q) Clock values 



V 



e 



join / 



Expressions 
join activity 



Values 



R,Q ::= {/i , . . . , /„} Sets of activity names 

a ::= {V,e,A) Activities 
V ::= {ci : pi,...,c„: /j^} Clocks' local views 



p ::= \ \ \ 2 



c 



Phases 



clock 



Figure 2: Run-time syntax of XIO |ciocks 



ready to advance the clock to the next phase (Q). Set difference /? \ Q identifies the activities yet to make 
progress on a clock; the clock phase only advances when all activities have quiesced (when R\Q = 
equivalently R = Q). The set of registered activities R also allows to enforce that an activity only operates 
on registered clocks. 

An activity a is composed of a set of clocks' local views V , an expression e under execution, and a set 
of sub-activities A. Each activity has its own perception of the global phase of a clock; the clocks' local 
view V is a map from clock names to natural numbers describing the local phase. The global phase of a 
clock and that local to one of its activities may diverge in case the activity issues a resume on the clock. 
Only when the activity issues a next, the local view of the clock and the global phase become in sync. 
At anytime, a clock's local view is at most one phase behind the global phase. Notice that an activity is 
itself a tree of activities, since each activity holds a set of (named) sub-activities. When evaluating an 
expression finish e, the activity starts sub-activities for evaluating expression e and all activities spawned 
by e. Otherwise, activities have no sub-activities. 

We augment the syntax of expressions at run-time with join /. Expression join I results from eval- 
uating finish e; label / identifies the activity that executes the body e of the finish expression and that 
produces the resulting value of the finish e expression. 

We present the small step reduction rules for XIO | docks in Figures |3] and |4] Reduction for activities 
(Figure |3]l, H;a — H';A;a', operates on a heap H and an activity a, and produces a possible different 
heap H', a set A of activities spawned during the evaluation of the expression in a, and a new activity a'. 
Label / is the name of activity a. 

Rule R-ASYNC is the only rule that affects the set of spawned activities A. The programmer specifies 
a list of clocks c on which the new activity is to be registered with. The newly created activity (named /') 
is added to the set R of activities registered with clocks c, and stored in the heap. The result of spawning 
an activity is the unit value (). The created activity is composed of a clock view holding, for each 
clock c in c, a copy of the global phase p, an expression e to be evaluated, and an empty set of sub- 
activities. Syntax H{c: h} describes a heap H' with a distinguished entry c: h; formally H'{c) = h 
if c = c' else H{c). The new activity inherits each clock c quiescence property, i.e., if / is quiescent on 
clock c so is /' (2' = if / G 2 then QU{1'} else Q). 

The language specification reads "Clocks are created using a factory method on xlO . lang . Clock. 
The current activity is automatically registered with the newly created clock" |8, page 207]. Expres- 
sion makeClock creates a new clock in the heap with initial phase 0, with I as the only registered ac- 
tivity, and with no resumed activities, (0, {/},0). The activity creating the clock maintains a local clock 
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{c} C domV r is fresh Q'^ifleQ then Q U {/'} else Q 



H{c: {p,R,Q)},i,s;iV,asyncce,A) -^iH{c: {p,RU{l'},Q')},i,s;{l' : ({c: p},i„j,e,0)}; (V, (),A) 

(R-ASYNC) 

c is fresh 



77;(y,makeClock,A') -^iH{c: (O,{/},0)};0; (V{c: 0},c,A') 
Q'Aiip = v{c) then QU{1} else Q I <^ Q 



(R-MAKE) 
(R-RESUME) 



H{c: {p,R,Q)y,{V,resumec,A) ^iH{c: {p,R,Q')yM{V,{),A) 
Ci ^ {c I V{c) = p,H{c) = {p,R,R)} C2 = {c\ V{c) = p,H{c) = {p + \,_,_)} Ci UC2 = domV 



H;{V,next,A)^iH{c: (p + 1,/?,0)},6C,;0; ({c: V(c) + Ij^ey, (),A) 

cGdomy H' = if R = {1} then H\{c} else H{c: {p,R\{l},Q\{l})} 
H{c: {p,R,Q)};{V,dropc,A) //';0;(y\{c},(),A) 

/() is fresh 



(R-NEXT) 
(R-DROP) 

(R-FINISH) 



H;{V, finish f-.A) ^/ //;0; (V, join lo,A{k- (^,^,0)}) 
H;{V,jomlo,{lo: (0,vo,0), : (0,v„,0)}) //;0; (0,vo,0) (R-JOIN) 



Figure 3: Reduction rules for activities H;a^i H;A;a 



H;A{1: {V,let x = v in e,A')} ^ H;A{1: {V,e[v/x\,A')} (R-LET-VAL) 

/ £ domH H; (V, e, A) -^i H';A"'; {V',e',A') 

H;A"{1 : {V, letx = e in e",A)} -> H';A"{1 : {V, let x = e'in e",A')},A"' ^ '^^^^ 

H;A' H';A" 

H;A{1: {y,e,A')} ^ H';A{1: {V,eA")} -ACTIVITY) 



Figure 4: Reduction rules for states H;A — > H;A 



view {c : 0} stored in V. Regarding expression resume the language specification reads "An activity 
may wish to indicate that it has completed whatever work it wishes to perform in the current phase of 
a clock c it is registered with, without suspending altogether" (page 208). Rule R-resume asserts that 
when the /-labelled activity issues a resume c, its label is recorded in the set of resumed activities R 
if the clock local phase is in sync with the clock global phase (p = V{c)); otherwise, the effect of the 
expression is discarded {p / V{c)), since the clock has akeady advance to the next phase. An activity 
may only perform a resume operation per clock per phase (I ^ Q). 

The language specification reads "Execution of this statement [next] blocks until all the clocks that 
the activity is registered with (if any) have advanced. (The activity implicitly issues a resume on all 
clocks it is registered with before suspending.) [. . .]. An activity blocked on next resumes execution 
once it is marked for progress by all the clocks it is registered with" (page 209). In our model, for 
simplicity's sake, the programmer must issue a resume on all held clocks before expression next. As 
rule R-NEXT states, expression next blocks the activity until all clocks have been resumed (Ci) or have 
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already advance their phases (C2). Notice that when activities are waiting on a clock c, the clock can be 
in one of three states: (a) there are non-quiescent activities on the clock and c is neither a member of Ci 
nor of C2; (b) all registered activities are quiescent on the clock, and so c is a member of Ci ; (c) the clock 
has advanced to the next phase thus becoming a member of C2. When an activity advances a clock global 
phase, it stops being a member of set Ci and becomes a member of set C2 for the remaining activities 
waiting on that clock. Since rule R-NEXT only updates the clock phase of those clocks belonging to Ci 
{H{c : {p + l,/?,0)}ceCi) ensures that the global clock state is updated only once. 

The language specification reads "An activity may drop a clock by executing c . drop ( ) . The activity 
is no longer considered registered with this clock" (page 209). With expression drop c, the /-labelled 
activity cedes its control over clock c: we remove c from clock view V, and remove activity identifier / 
from both sets R and Q. Two consequences of dropping a clock c are: a) activities waiting on clock c are 
no longer blocked because of this activity; b) when executing a next expression, this activity no longer 
waits for clock c. In case / is the only activity registered with clock c, it is safe to deallocate the clock, 
so that the clock's heap space can be reclaimed without resorting to garbage collection. The language 
specification reads "An activity A executes finish S by executing S and then waiting for all activities 
spawned by S (directly or indirectly [. . .]) to terminate" (page 196). Expression finish e creates a child 
activity and evaluates into expression join /q (rule R-FINISH), which in turn blocks while there exist 
sub-activities running. When all sub-activities have reduced to a value, activity / (join Zq) evaluates to 
the value in its sub-activity Iq and garbage collects all other sub-activities (rule R-JOIN). 

The reduction for states (Figure |4]l, S — )• 5", allows for non-deterministic choice of which activity / 
to evaluate (rule R-ACTIVITY), capturing the concurrency present in XIO computations. We evaluate 
the let binding from left-to-right (rule R-LET), when the left-hand-side expression becomes a value, we 
substitute this value for variable x in the continuation expression e (rule R-LET- VAL). 

Example Recall the example from Section [2] Consider a loading function that sets up the initial state 
from a given expression, which in this case is So, an empty heap and an activity evaluating the code in 
the example under a dummy let . State So reduces in two steps, using rules R-FINISH and R-LET. The 
grey boxes highlight a redex and also the corresponding contractum. 

So = 0; {h : (0, let z = finish let x = makeClock in ( finish (async eo);e6) in (),0)} 
V ' 

Example from Section[2] 

where eg is (async x {e\; resume x;e2; next; ; drop x) ) ; resume x; ^4 ; next; ej ; drop x. We perform two 
reduction steps to illustrate the effect of expression finish on the sub-activities of h. 

0; {h : (0, let z = join I2 in (), { I2 : (0, let x = makeClock in ( finish (async eo);e(,),(Z)) })} 

From this state on, while join remains blocked, we apply rule R-ACTIVITY to evaluate the child ac- 
tivities of h. We perform four further reduction steps (R- ACTIVITY, R-LET, R-MAKE, and R-LET- VAL) 
and observe how expression makeClock updates the heap and the clock view of activity li- 

{c: (O,{/2},0) };{/i: (0,letz = join/2in(),{/2: ({c: 0},letx= c in ( finish (async eo); eg), 0)})} 

The non-determinism of our semantics now allows for various different reductions. A possible out- 
come of a (multi-step) reduction is 

{c : (O,{/2,^3},0)};{/i : (0, let z = join I2 in (),{/2 : {{c '■ 0}, ( resume c ; next; £5 ; drop c),0), 

h : ({c : 0}, (resume c; ^2; next; ^3; drop c),0)})} 
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H;A{1 : {V, let x = async c e in e',A')} G Error if c ^ dom// or c dom V (E-ASYNC) 

//{c: 0};A{/: (V, let = resume c in e, A')} G Error if Z G 2 or c dom// or c domV 

(E-RESUME) 

H;A{1 : {V, let = drop c in e,A')} G Error if c dom// or c domV (E-DROP) 

H;A{1: (V, let ;c = next in e,A')} G Error if V{c) = p,H{c) = {p,.,Q), and 

I Q, for some c (E-NEXTl) 

H;A{1 : (V, let ;c = next in e,A')} G Error if c G domV and c ^ domH, for some c 

(E-NEXT2) 

//;A{/: (y,v,_)} G Error ifVT^O (E-ACT) 
H;A' £ Error 

p — ^ TT (E-ACT-SET) 

H;A{1: _,A')} G Error ^ ^ 

Figure 5: The set Error of run-time errors 

We now illustrate the case when activities h and h are evaluating expressions and concurrently. 

R- ACTIVITY, R-LET R-RESUME R- ACTIVITY, R-LET-VAL 

{c : (0,{/2,/3},{ ^2 : (0, let z = join h in (),{/2 : ({c : 0} , (next; ; drop c),0), 

Z3 : ({c : 0}, ( resume c ; ^2; next; ^3; drop c),0)})} 

R- ACTIVITY, R-LET R-RESUME -^/j 

{c: (0,{Z2,/3},{/2, /3 })};{/! : (0,join Z2,{/2 : ({c:0},(next ; ^'5 ; drop c) , 0) , 

/3 : ({c : 0}, ( ; 62; next; e3; drop c),0)})} 

R- ACTIVITY, R-LET R-NEXT — ^/^ 

{c:(l,{/2,/3}, 0)};{/i :(0,letz = join/2in(),{/2:({c: 1 },( () ; ; drop c) , 0) , 

h : ({c : 0}, (();e2;next;e3;drop c),0)})} 

After activity evaluates resume c, activity I2, which is blocked evaluating next, progresses, thus 
allowing expressions 62 and to execute in parallel. Notice that activity I2 remains in phase 0, while 
activity Ij, is in phase 1 . 

Run-time errors Run-time errors is the smallest set Error of states generated by the rules in Figure |5] 
The notion is consistent with all the conditions documented to raise exception ClockUseException, as 
discussed in the XIO language specification report [8 |. The type system we present in Section|4]allow us 
to reject, at compile time, programs that can potentially throw a ClockUseException. 

During an async operation, an activity cannot transmit unregistered clocks through its first argument 
(rule E-ASYNC). Similarly, activities can only perform resume or drop operations on clocks they are 
registered with (rules E-RESUME and E-DROP). In particular, it constitutes an error for an activity to 
drop a clock twice, or to resume a clock more than once (for the same phase) or after dropping it. We 
achieved a fine grained control over the clocks an activity is registered with. Specifically, it is possible 
to devise, at compile time, whether an activity resumed or dropped all of its held clocks, as manifest 
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unit I clock(a) 



Types 



Figure 6: Syntax of types 



^,a\- clock(a) 



^ I- unit 



(T-WF-C, T-WF-U) 



— r,c: clock(a);^,a h c: clock(a) r;^\- (): unit 

r,x: t;S£\-x: t 

(T-VAR, T-CLOCK-REF, T-UNIT) 

F;^ h vi : clock(ai) • • • F;^ h v„ : clock(a„) a,- / tty, if / / 7 a, not in F 



from our typing rules later. Therefore, it constitutes an error when an activity evaluates a next expression 
before resuming all its clocks (rule E-NEXTl). It is also an error when upon evaluating a next there 
is a held clock that is not in the heap (rule E-NEXT2). Furthermore, an activity cannot evaluate to a 
value without dropping all of its clocks (rule E-ACT). Rule E-ACT-SET allows error propagation from 
sub-activities. 

Earlier versions of the language specification report (until version 2.05) included two additional error 
conditions we quote: 

• "It is a static error if any activity has a potentially live execution path from a resume statement on 
a clock c to a async spawn statement (which registers the new activity on c) unless the path goes 
through a next statement" (page 153, version 2.04). (See example 2, Section]?]); 

• "While executing S [the body of a finish], an activity must not spawn any clocked asyncs. (Asyncs 
spawned during the execution of S may spawn clocked asyncs.)" (page 141, version 2.04). 

Our type system guarantees soundness in presence of these two conditions. 

4 Type System 

This section presents a type system that uses singleton types to track clock usage throughout a program. 

For types we rely on an additional base set of singleton types ranged over by a. The syntax of types, 
depicted in Figure]6j introduces the type unit of unit values, and the type clock(a) of a particular clock. 
We assign a different type to each clock in order to ensure the correct usage of the clock constructs within 
a program. 

The type system for XIO | docks programs is defined in Figures ]?] and ]8] A typing F is a map from 
variables (or activity labels) and clocks to types. We write domF for the domain of F. When x domF 
we write F,.jc : T for the typing F' such that domF' = domFU {x}, T'{x) = T, and T'{y) = T{y) for y i^x. 
The type system also uses sets of singleton types, ranged over by for registered clocks, and £2, for 
quiescent clocks. 



F;^hvi...v„: {«!,...,«„} 



(T-CLOCK-SEQ) 



Figure 7: Typing rules for values and for well-formed types 



120 XIO clocks 



T;M\-v: z a is fresh 

(T- VALUE, T-MAKE) 



r;^;^hv: (t,^,^) r;,^^;^ h makeClock: (clock(a),<^U{a},^) 

r;=!^h v: clock(a) a ^ T;^ h v: clock(a) 



T;,:^;^ h resume v: (unit,^;^U{a}) T;^;^ h drop v: (unit,.^\{a},^\{a}) 

(T-RESUME, T-DROP) 

r;^hv:^' r;^';^n^'hf': (_,0,0) 



r;^;^hasyncve: (unit,^;^) 

r;0;0he: (t,0,0) 



r;^;^h finish £>: (t,^;^) 



r;^;^h let ;c = £'i ine2: (t',=^",^" 
Figure 8: Typing rules for expressions 



r;^;^hnext: (unit,^;0) (T-async,T-next) 

(T-FINISH) 
(T-LET) 



The typing rules for values and for well formed types (Figure [7]l are simple to follow. Well-formed- 
ness for clock types (rule T-WF-C) ensures that activities only make use of clocks they are registered 
with. Rule T-CLOCK-SEQ ensures that different clocks (as those in the heap) have distinct singleton 
clock types, a property that is crucial for establishing type safety. For typing expressions we use a type 
system (Figure [8]) that records the changes made to the set of registered clocks, either by creating or 
dropping clocks, and to the set of quiescent clocks (using resume and next) of an expression. Typing 
judgements are of the form F;^;^ h e: [r,^' ,^') meaning that expression e is well typed assuming 
the types for the free identifiers in F, the registered clocks in and the quiescent clocks in J2. The 
type of an expression is a triple recording the type T of its value, as well as the registered and the 
quiescent J3' sets after execution of the expression. 

Most typing rules are straightforward. When creating a clock (rule T-MAKE) we associate a new 
singleton type a with the clock and include it in set of clocks registered by the activity (=^U {a}). 
Rule T-RESUME, which asserts that "an activity may invoke resume () only on a clock it is registered 
with, and has not yet dropped" (page 208, vide rule T-VAR), marks clock a as quiescent. Notice that a 
clock cannot be resumed more than once for the same phase (a ^), contrary to the language reference 
that reads, "Nothing happens if the activity has already invoked a resume on this clock in the current 
phase" (page 208). A drop v expression removes clock v from both the sets ^ and J3, thus the clock 
cannot be passed to new activities, be the target of a resume expression, or be dropped again. 

For expression async c e, the language reference reads "Starts a new activity, initially registered with 
clocks [v], and running [e]. The activity running this code must be registered on those clocks" (page 207, 
w.r.t. rule T-ASYNC). Rule T-ASYNC asserts that when an activity spawns another activity registered on 
a sequence of clocks, the quiescent property of the clocks is preserved by propagating the information 
about the quiescent clock a {J2r\^). Moreover, the new activity must have dropped all its clocks upon 
termination, contrary to the language reference that reads, "All activities are automatically deregistered 
from all clocks they are registered with on termination (normal or abrupt)" (page 207). An activity 
cannot share a clock it does not hold, as noted in the language reference, "lacking that registration, 
cannot register a sub-activity on it [a clock] with async" (page 208). Expression next marks the end of 
a phase; it checks that all clocks have been resumed and clears the quiescent clocks for the new phase 
(rules T-NEXT). 
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The finish construct may interfere with clocks and cause programs to deadlock. In order to avoid 
such situations we prevent the body of a finish e expression (e) from accessing any clock already de- 
fined, thus eliminating (nested) dependencies between clocks and finish . Rule T- finish also forces e to 
unregister from all clocks it has created, and therefore finish e has no effect on registered and quiescent 
clocks. This follows the semantics of the current version of XIO that reads, "Inside of f inishjS}, all 
clocked asyncs must be in the scope an unclocked async" (page 210). Refer to the examples below for 
further discussion on the deadlock problem. When typing a let expression (rule T-LET), its continua- 
tion €2 is typed taking into consideration the effects produced by expression ei . The type of the let is 
that of 62, as usual. 

We have deliberately deviated from the standard XIO semantics in three cases: next, drop, and 
resume. The reasons for such deviation are: (a) to illustrate the power of singleton types in keeping 
track of clocks, (b) to simplify the (operational and static) semantics, (c) to enforce a programming 
discipline that may avoid potential bugs, and (d) because the compiler has enough information to suggest, 
or automatically insert, code fixes (e.g., by enumerating the clocks that need to be dropped before a next; 
see examples below). 

Below we discuss a few XIO |ciocks programs and the semantic guarantees our type system enforces. 
We decorate the examples with the typing assumptions (F, ^) holding for each expression. 

Example 1: Aliasing Our first example concerns clock aliasing, only introduced in XIO in version 
2.01. The example may read a bit trivial but illustrates more sophisticated aliasing situations, derived 
for example from procedure calls. Clearly a type system with linear control like the one we are going to 
present allows to relieve such a restriction. 



// activity ai 1 

let X = malseClock in ( // {x: clock (a)}, {a}, Id 2 

async X ( //activity 02 // {x:lock(a)},{a},(d 3 

let y = X in ( // {x:clock(a),y:clock(a)},{a},(d 4 

resmnex; // {x: clock(a),y: clock(a)},{a},{a} 5 

dropy) // {x:clock(a),y: clock(a)},%,Q) 6 

); // {x:clock(a)],{a],% 7 

dropx) // 0,0,0 8 



In our case the code is typable, assigning the same singleton type clock(o:) to both x and y. Upon 
introducing variable x (line 2), it gets assigned type clock(a) {vide rules T-LET and T-make). Vari- 
able y (line 4) gets assigned type clock(a), the type of x (again using rules T-LET and T-make). 

Example 2: Resume state inheritance Our second example deals with a restriction the language ref- 
erence disallowed up until version 2.04, "A potentially live execution path from a resume statement 
on a clock c to an async spawn statement" (page 153, version 2.04). Our operational semantics al- 
lows the forked activity to inherit the resume state (resumed/not resumed) of the parent activity {vide 
rule R-ASYNC) and therefore preserves the quiescence property of clocks and avoids a race condition on 
the clock. Notice that the forked activity 02 inherits the quiescent state of clock a (line 4), resumed at 
line 3. 



// activity a\ 
let X = makeClock in ( 
resume x; 



// {x:clock(a)],{a],(b 
// {x: clock(a)},{a},{a} 



1 

2 
3 
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async X ( //activity a2 // {x: clock (a)}, {a}, {a} 4 

next; // {x: clock (a)}, {a},® 5 

dropx // {x: clock (a)},®,® 6 

); // {x:clock(a)},{a},{a} 7 

dropx) // {x:clock(a)},(l),Q) 8 



Example 3: Race condition generated by not inheriting the resume state Describes a race condition 
triggered by clock synchronisation. Activity m creates a clock x, starts a second activity 02 registered 
with clock X that, in turn, resumes on x and starts a third activity also registered with x. 



// activity a\ 1 

let X = makeClock in ( // {x: clock (a)}, {a}, ^ 2 

async X ( //activity a2 // {x:clock(a)},{a},d 3 

resume x; // {x: clock (a)}, {a}, {a} 4 

async X ( //activity 03 // {x:clock(a)},{a},{a} 5 

next; // {x: clock (a)}, {a},® 6 

dropx // {x: clock (a)},®,® 7 

); // {x: clock (a)}, {a}, {a} 8 

next; // {x: clock (a)}, {a},® 9 

dropx // {x: clock (a)},®,® 10 

); // {x:clock(a)},{a},(l) 11 

resume x; // {x: clock (a)}, {a}, {a} 12 

next; // {x: clock (a)}, {a}, (d 13 

dropx) // {x: clock (a 14 



The race condition might occur because after a2 resumes on x (line 4), either activity ai may advance 
clock X phase by executing next (line 13) or 02 may register a new activity as with x (line 5), blocking ai 
until activity a^ executes its next instruction (line 6). By inheriting the resume status of clock x, activ- 
ity as does not block activity ai and the race condition disappears (vide rule R- ASYNC in Figure |3] and 
rule T- ASYNC in Figure [8]l. 

Example 4: Resume after resume The next example deals with resuming after resuming, a pattern 
accepted in XIO. Rule T- RESUME rejects the program below, since it is able to determine that clock x is 



resumed twice. 

// activity a\ 1 

let X = makeClock in ( // {x: clock (a)}, {a}, ^ 2 

resume x; // {x: clock{a)},{a},{a} 3 



resume x) // error: clock x already quiescent for activity ai 4 



Example 5: Explicit drops Unlike XIO, we have decided to explicitly deregister activities from clocks 
upon activity termination. Our type system keeps track of the clocks an activity is registered with, 
and rejects programs with activities that finish before deregistering from all its clocks. Clocks without 
registered activities can be safely garbage collected {vide rule R-DROP). The following example fails 
to type check, since the launched activity does not drop clock x. The compiler may easily suggest an 
appropriate fix: adding a drop x after the next instruction on line 5, or even automatically introduce such 
an instruction. 
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// activity a\ 1 

let X = makeClock in ( // {x: clock (a)}, {a}, ^ 2 

async X ( //activity a2 // {x:clock(a)},{a},® 3 

resume x; // {x: clock (a)}, {a}, {a} 4 

next // {x: clock (a)}, {a},® 5 

); // error: activity a2 did not drop x 6 

drop x) 7 



Example 6: Finish/async deadlock Finally, we discuss the interplay among finish, async, and clocks, 
which may cause programs to deadlock. The following program deadlocks because activity ai is waiting 
on next (line 6) for activity a\ to advance on x, which is planned to occur at line 10, but ai is waiting on 
finisli (line 3) for activity a2 to terminate, so a\ never reaches line 10 and the program deadlocks. 



// activity a\ 1 

let X = makeClock in ( // {x: clock (a)}, {a}, % 2 

finish // {x:clockia)},(b,^ 3 

async x ( // activity a2 // error: clock x is not in scope of finish 4 

resume x; 5 

next ; 6 

drop x 7 

); 8 

resume x; 9 

next; 10 

dropx) 11 



The cause for deadlock is that activity is registered with a clock that is defined outside the enclosing 
finish: clock x is defined in line 2, whereas the finish expression extends from line 3 to line 8. Our type 
system rejects this program, because when typing a finish e expression we type check e in an environment 
with no registered clocks {vide rule R-FINISH). 



Example 7: Clocked finish/clocked async Version 2.10 of the XIO language introduces keyword 
clocked to prefix async and finish. 

In the most common case of a single clock coordinating a few behaviors, XIO allows coding 
with an implicit clock. [...] A clocked finish introduces a new clock. It executes its 
body in the usual way that a finish does — except that, when its body completes, the activity 
executing the clocked finish drops the clock, while it waits for asynchronous spawned asyncs 
to terminate. A clocked async registers its async with the implicit clock of the surrounding 
clocked finish. [...] Clocked finishes may be nested. The inner clocked finish operates in 
a single phase of the outer one. 

This featured introduced in the language is purely "syntactic sugar," which makes the common prac- 
tice of creating a single clock and sharing it among activities simpler. The following two code listings 
present a program with and without the syntactic extension side-by-side. On the left column we show 
an activity written on a language that resembles XIO [8|. Remember that, in XIO, expression next im- 
plicitly issues a resume and also that activities implicitly drop all clocks on exit. On the right column 
we find an equivalent activity written in our language. Activity a\ spawns three activities a2, aa, and a4. 
Activities C2 and ^3 share the same clock, say c\, whereas activity a^^ holds a different clock, say C2, but it 
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does notholdci- In the first phase of clock ci the system executes concurrently ^i, ^3, and activity a4. In 
the second phase of clock c\, activity 04. has terminated, and expressions 62 and 64 execute concurrently. 



// activity a\ 
clocked finish ( 

clocked async ( // activity ai 
e\ 

next; 

); 

clocked async ( // activity a^ 

^3 

next; 

64 



) 

clocked finish ( 



clocked async ( // activity 
next; 

€4 



) 



a4 



) 



// activity a\ 
finish 

let c 1 = makeClock in ( 
async c\ { // activity a2 
e\ 

resume c 1 ; next ; 

£2 

drop c 1 ; 

); 

async cl ( // activity a^ 

e?, 

resume c 1 ; next ; 

€4 

drop cl; 

); 

finish 

let c2 = makeClock in ( 



async c2 ( // activity 
resume c2; next; 

€4 

drop c2 

); 

drop c2 

); 

drop cl 



//0,0,0 

//{cl:clock(al)},{al},<l) 
//{cl: clock (al)},{al},(d 

//{cl:clock(al)},{al},(l) 

//{cl:clock(al)}33 

//{cl:clock(al)],{al],(b 

//{cl:clockial}},{al},(b 

//{cl:clock(al)},{al}3 



) 



//{cl:clock(al)},^,^ 
//{cl:clockial)},{al},^ 
//{cl:clock(al)},(d,id 
// {cl. ■ clock (al), 
// c2: clock (a2)},{a2},(d 
a4 //{ cl : clock ( al ), 

// c2: clock (a2)},{a2},(d 
// {cl: clock (al), 
// c2: clock (a2)},{a2}, id 
//{cl : clock ( al ), c2: clock f a2 j},0, 
//{cl:clock(al),c2:clock(a2)},{a2}, 
//{cl : clock ( al ), c2: clock f a2 j},0, 
//{cl:clock(al)},{al},(d 

//{cl:clock(al)}A® 
//0,0,0 



The activity (on the right) obtained by expanding clocked finish and clocked async is still typable 
with the type system we propose. 



5 Main results 

This section is dedicated to the study of the main result of our system, namely typing preservation and 
type safety for typable programs. 

We are only interested in well-formed states (the rules in Figure |9] check whether a state is well- 
formed). A state is well formed if for each clock, the set of registered activities with the clock contains 
exactly those activities that can manipulate it. State 

{c: (_,0,_)};{/: ({c: _},let _ = next in _, _)} 

is ill formed, since activity / uses clock c and is not registered with c. The activity is able to advance c's 
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ch 0: 



c\-A,{l: (y,-,A')}: Si USiUdomVnjc} 

(WF-ACT-CLOCK, WF-ACT-CLOCK-E) 

^- - r;Ah0:o (WF-HEAP, WF-HEAP-E) 



r;Ah//,{c: {.,S,Q)}:o 
H{ci) = l&S^i HhA:o HhA':o 



//h0: o 



(WF-ACT-SET, WF-ACT-SET-E) 
(WF-STATE) 



HhA,{l: ({ci: _,...,c„: .},-,A')}- <> 

HhA: o r-AhH: o 
rhH;A: o 

Figure 9: Well-formed states 



r,/: T;^;^hjoin/: (t,^,^) (T-join) 
Figure 10: Typing rules for run-time expressions 

phase without becoming quiescent on c. State 

{c: (_,{/,/',...},_)};{/: (0,_,_),r:({c: _},-,-),.••} 

is also ill formed, since activity / is mentioned as registered with clock c and is not part of Z's local view 
(which is 0). Any other activity registered with c {I' in the example) is bound to deadlock because / will 
never quiesce on c. 

In order to state our results we must be able to type check run-time expressions as well as machine 
states. The typing rules for run-time expression join / and for machine states and activities are depicted 



in Figures 10 and 1 1 The type of a join / expression (rule T-JOIN) is that of activity /. Notice that join / 
is the result of evaluating a finish e expression (rule R-FINISH) that is, in fact, the type of e (rule T- 
FINISH). It is worth noticing that a heap H is well typed if each clock is assigned to a different singleton 
type and if the clocks allocated in the heap are exactly those of typing T (rule T-HEAP where C is the 
set of all clocks). Moreover, activities may only resume on registered clocks. An activity (y,e,A) has 
the type of its expression e (rule T-ACT), which must unregister from all its clocks before terminating, 
since after evaluating e it is expected that the set of registered clocks should be empty. Rule T- STATE 
incorporates the definition of well-formed states into the type system. The remaining typing rules should 
be easy to follow. 

Lemma 1 (Weakening). Let a be a variable or a clock name. 

1. IfHhA-.o then H,c:hhA:o. 

2. //n^hv: Tthenr,a: r'hv: T. 

3. IfFhV: ^ thenr,a: rhV: 

4. IfF-^-^he: T thenT,a: T,^;^'r e: T. 
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r;^hci...Cn: ^ 
rh{ci: _,...,c„: _}: ^ 
rhV:^ r;^;^he: (t,0,0) ThA 

rh(V,e,A): T 
r h ai : Ti • • • r h a„ : T„ 
r, /i : Ti ,...,/„ : T„ h {/i : ai : a„} 

F;.^ h ci . . .c„ : ^ {ci, • • • ,c„} = domr|c 
rh {ci : hi,. ..,€„: K} 
rh//;A: o rh// rhA 
rh//;A 

Figure 1 1 : Typing rules for machine states 

Proof outline. 1. By induction on the derivation of the typing rules. Case WF-ACT-SET-E is di- 
rect. For case WF-ACT-SET we use the induction hypothesis to prove that H ,{c: K] \- A: o and 
//, {c : K]\- A' : o; the remaining conditions are given by the hypotheses. 

2. By inspecting the typing rules. 

3. We apply rule T-VIEW to typify the clocks of the view, then we prove T-CLOCK-SEQ with (2). 

4. By induction on the derivation of the typing relation. Cases T-MAKE, T-NEXT, and T-JOIN are 
direct. Case T-RESUME and T-DROP are proved similarly, using (2) to typify clock v. The proof 
for cases T-FINISH, T-ASYNC, and T-LET follow by induction hypothesis. For case T-ASYNC we 
also use rule T-clock-seq and (2) to typify the clocks of the arguments. 

□ 

Notice we do not allow heap weakening for it would introduce in the type environment clocks not 
present in the state. 

Lemma 2 (Substitution). Ifr\^\-v: xandT,x: T,^;^\-e: T thenT;^;^^ e[v /x]: T. 

Proof outline. For T- VALUE we analyse two cases: when the value is the variable being substituted, 
and when it is not replaced. For the former case, we apply Lemma [T] on the first hypothesis. For 
the latter case we use rule T-VAR. Rules T-MAKE, T-NEXT, and T-JOIN are direct. Cases T-DROP 
and T-RESUME follow by induction hypothesis. Rule T-ASYNC is the most complex. For the clocks 
being shared we use Lemma [T] and the second hypothesis. For the expression being spawned we apply 
the induction hypothesis. Rule T-FINISH is proved similarly to T-ASYNC, but simpler, since T-FINISH 
has no arguments and its set of clocks is empty. □ 

Lemma 3 (Preservation for activities). IfT\-H and Fh V : =S and =S C ^ and F;^;^ \- e: T and 
FhAandle dom// and H; (V,e,A) ^, H';A"; {V ,e' ,A'), then T' h H' and T'^V: ^' and S.' C ^' 
and V-M'\ ^'^e':T and V h A\A", for some V D F. 

Proof outline. Despite the scary look of the statement, its proof is a routine inspection of the rules in the 
relation //;(y,e, A) -^i H';A";(V' ,e' ,A'). □ 

Lemma 4 (Preservation for XIO |ciocks)- IfF h S and S ^ S' then F' h S' and F C F'. 



(T-VIEW) 
(T-ACT) 
(T-ACT-SET) 
(T-HEAP) 
(T- STATE) 
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Proof outline. By induction on the derivation of the relation S — S'. In all cases we build the deriva- 
tion tree for F h 5 using rules T-STATE, T- ACT-SET, and T-ACT, collect the hypotheses, use the above 
Lemmas, and then build a tree for V h S' using the same typing rules. The base cases are when the 
derivation ends with rules R-LET-VAL and R-LET. For R-LET-VAL we take F' = F and use the substitu- 
tion Lemma[2] For R-LET we use the (specially crafted) preservation for activities (Lemma[3]l, as well as 
the weakening (Lemma [T]l for the extant activity set A. The induction step is when derivation ends with 
rule R- ACTIVITY; in this case we use the Weakening Lemma. □ 

Theorem 5 (Type Safety). IfF h S and S S', then S' ^ Error. 

Proof outline. We first establish that F' h S' using preservation (Lemma[4]). Then we proceed by contra- 
diction. The contradiction is proved by induction on the definition of Error predicate. For the base cases 
of resume, drop, and async we build the derivation trees for the errors in Figure [5} to conclude that 
F' h V : =^ and F';^ I- c : clock(a). Sequent F' h V : ^ is derived from rule T-VIEW, which effectively 
establishes a one-to-one correspondence between the clock names c in V and the singleton types a in ^. 
On the other hand, sequent F';^ h c: clock(a) is derived via rule T-WF-C, which says that a £ J^. 
Since a £ the correspondence allows us to conclude that c £ domV. Establishing that v G domH is 
easier. Given that F' h H, we conclude that domH = dom(F' |c), and from sequent r';^\- c: clock(a) 
we know that c G domF', hence done. □ 

In Section |3] we introduced a loading function that builds the initial machine state corresponding 
to a given expression. Such a state is typable if the expression is. Let load(e) be defined as the state 
0; {I : (0, let x = e in uiiit,0)}. Then we have: 

Lemma 6. //F;0;0 he:T then F h load(e). 

Our final result guarantees that a well-typed expression does not reduce to an error. 

Corollary 7. IfF;®;® \- e: T then load(e) does not reduce to an Error 

Proof. From the lemma above and Theorem |5] □ 

We anticipate a progress property for typable processes. Typability ensures that processes do not get 
stuck when dropping a clock that is not in its clock set anymore, or when otherwise trying to access a 
clock that it not allocated in the heap. The remaining case is next where the activity waits for set C\ (the 
set of quiescent clocks the activity is registered with) to grow until becoming (together with C2 — the set 
of clocks that have already advance their phase) the clock set of the activity. And this is bound to happen 
for both next and drop, since in each activity both implicitly resume all clocks. We foresee as well that 
typability also rules out programs that deadlock, since finish expressions can only use clocks created in 
its body expressions. 

6 Discussion and future work 

We study two synchronisation constructs of XIO: a primitive finish that waits for the termination of ac- 
tivities (lightweight threads), and clocks (a generalisation of barriers). To better understand the language 
we define an operational semantics and a type system (alternative to the constraint-based system [9]) for 
a subset of XIO called XIO Idocks- Our main result is type safety for typable programs (Theorem|5]l. 

Our semantics represents clocks in the heap as triples {p,R,Q) relying on two sets for recording 
the registered activities R and the quiesced activities 2 on a clock. Implementing operations that work 
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with sets is costly; for instance rule R-NEXT needs to compute sets Ci and C2, by checking if sets R 
and Q are equal, and then verify if Ci U C2 = domV . Should we make a real life implementation of the 
proposed semantics, set operations would have a significant impact on performance. We sketch a much 
faster approach that chooses to represent clocks as triples {p,r,q) describing the clock phase, as before, 
but taking r and q as the cardinal numbers of sets R and Q. With this representation we lose information 
about the identity of the activities registered with a clock and, in particular, we cannot determine if an 
activity has already resumed in the current phase (vide rules R-ASYNC and R-RESUME). To overcome 
this problem we need to enrich the clock local view with an indicator of whether an activity has performed 
a resume in the current phase. Thus, a clock local view becomes a pair {p,b) containing the current clock 
phase p (as before) and the resume boolean indicator b, describing when the activity has resumed. With 
this information it is straightforward to adapt rules R-ASYNC, R-MAKE, R-RESUME, R-NEXT, and R- 
DROP. For instance, rule R-RESUME only updates the clock global view ^ + 1) whenever its local 
view indicator is false. Also, rule R-NEXT needs to set r to zero when advancing the clock global phase, 
and to clear the indicator b upon advancing the clock local phase. Checking that all activities registered 
with a clock have quiesced amounts to compare two integer values (r = s), instead of two sets R and Q 
as before. The main reasons for not adopting the semantics just sketched are that the chosen semantics 
needs fewer rules and is easier to read and understand. 

We intend to investigate imperative features of the language, specially those related with clocks, 
and also other language constructs. The finish construct is not only used to wait for the termination 
of sub-activities, but also, as the language reference reads, "A collection point for uncaught exceptions 
generated during the execution of S [the body of a finish]" ||8] page 196]. Enriching our model with 
exceptions seems like a natural, promising follow-up of our work. The language report also reads, "XIO 
does not contain a register statement that would allow an activity to discover a clock in a data structure 
and register itself on it" (page 208); we would like to study type-safe extensions to the language that 
might alleviate this restriction in controlled situations. Furthermore, we expect to extend our results 
to XIO Iciocks equipped with recursion or some form of iteration. Futures are a form of a function that 
evaluates asynchronously, like an activity, but can be forced to finish locally to return a value. The 
semantics of a future, in what regards termination, is like the finish construct, but its use cases are 
different. We would also like to allow futures to register themselves with clocks, a feature missing in 
XIO. 

Phasers are a coordination construct that unifies collective and point-to-point synchronisations with 
performance results competitive to existing barrier implementations [10 J. Phasers can be seen as an 
extension over clocks that allow for more fine-grained control over synchronisation modes. Phaser 
accumulators are reduction constructs for dynamic parallelism that integrate with phasers [TTl. Although 
further investigation is needed, we believe our work can be extended to accommodate phasers and phaser 
accumulators, specially with regards to the operational similarities between clocks and phasers. 
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